1. Field of the Invention
The present invention relates to a method, system, program, and data structures for generating a user interface.
2. Description of the Related Art
One challenge for programmers is implementing a user interface that interacts with a program to provide data to the program. One solution is to integrate the user interface within the application program itself. The problem with such an approach is that the application program has to be modified in order to extend the user interface to alternative computing platforms or extend the application program to use different types of user interfaces. To address this problem, many programmers utilize the Model View Controller (MVC) architecture to design a user interface. FIG. 1 illustrates the three components of the Model View Controller, a Model 2 which provides the core functionality or the application program code that processes input and generates output, a View 4 which comprises the specific user interface or program that renders and presents data to the user, which may comprise a command line interface, windows-style interface, browser, etc., and a Controller 6 that is a program that controls how the view presents data and receives user input. The View 4 maintains consistency in presentation across Models 2 and forwards any user input or actions to the Controller 6. In a graphical user interface (GUI), the user input to the View 2 may comprise textual data, menu clicks, selection of buttons, etc.
In the MVC architecture, the Controller 6 is programmed to cause the View 4 to present certain information to the user and receive user entered input, which the Controller 6 then returns to the Model 2 for processing therein. The Controller 6 may maintain a series of rules specify an order and format for providing questions to the View 4 to present to the user to gather information for the Model 2. The Controller 6 selects the View 4 to use to present the data based on user input and Model 2 action outcome(s). In this way, the Controller 6 establishes communication between the View 4 and the Model 2. The View 4 and Controller 6 combined comprise the user interface. The Model 2 may further notify the View 4 of any updates or changes in data to render for the user.
One advantage of the Model View Controller (MVC) architecture is that the Model 2 has absolutely no dependence on the external representation of information. This permits reusability by allowing programmers to independently change input sources and output formats without affecting the Model 2. In other words, the Model 2 deals with pure information that has no attached external meaning. The Model 2 has no responsibility for translating the format of input data or determining how output data is displayed; this is the role of the Controller 4 and View 6 components. With this architecture, the Model 2 can be used with different View 4 and Controller 6 components. Further, all Views 4 to be displayed are known beforehand and selected by the Controller 6.
One drawback with the Model View Controller (MVC) architecture is the lack of any capability for the Model 2 to request specific input from the user depending on application processing outcomes. For instance, if the input from the user needed by the Model 2 varies depending on the outcome of certain internal processing operations or the information the Model 2 needs cannot be known in advance, then the Controller 4 cannot be programmed to know in advance the presentations to make and data to gather because the presentation to make and data to gather may vary at certain processing points.
One solution would be to build capabilities into the Model 2 to directly interact with a particular View 4 to query the user. However, such an approach is disadvantageous because the Model 2 is no longer separated from the user interface and is now integrated with a particular user interface or View 4 component. Such a solution does not allow easy extension of the Model 2 to other Views 4 because the Model 2 must be supplemented with code to directly utilize alternative Views 4. Further, such a solution contradicts one of the principles of operation of the Model View Controller, which is to maintain the Model 2 entirely separate from the View 4 and Controller components managing the user interface.
For these reasons, there is a need in the art to provide improved techniques for a Model 2 to request information from a View 4 in a manner that maintains the Model 2 separate from the Controller 6 and View 4 user interface components.